…e is provided

Fixes rust-lang#132784

Various types can be used as method receivers, such as Rc<>, Box<> and
Arc<>. The arbitrary self types v2 work allows further types to be made
method receivers by implementing the Receiver trait.

With that in mind, it may come as a surprise to people when certain
common types do not implement Receiver and thus cannot be used as a
method receiver.

The RFC for arbitrary self types v2 therefore proposes emitting specific
lint hints for these cases:
* NonNull
* Weak
* Raw pointers

The code already emits a hint for this third case, in that it advises
folks that the `arbitrary_self_types_pointers` feature may meet their
need. This PR adds diagnostic hints for the Weak and NonNull cases.

I mixed it up with RUSTC_CURRENT_VERSION unfortunately. Also improve the
formatting of the macro invocation slightly.

Suggest using deref in patterns

Fixes rust-lang#132784

This changes the following code:
```rs
use std::sync::Arc;
fn main() {
    let mut x = Arc::new(Some(1));
    match x {
        Some(_) => {}
        None => {}
    }
}
```

to output
```rs
error[E0308]: mismatched types
  --> src/main.rs:5:9
   |
LL |     match x {
   |           - this expression has type `Arc<Option<{integer}>>`
...
LL |         Some(_) => {}
   |         ^^^^^^^ expected `Arc<Option<{integer}>>`, found `Option<_>`
   |
   = note: expected struct `Arc<Option<{integer}>>`
                found enum `Option<_>`
help: consider dereferencing to access the inner value using the Deref trait
   |
LL |     match *x {
   |           ~~
```

instead of
```rs
error[E0308]: mismatched types
 --> src/main.rs:5:9
  |
4 |     match x {
  |           - this expression has type `Arc<Option<{integer}>>`
5 |         Some(_) => {}
  |         ^^^^^^^ expected `Arc<Option<{integer}>>`, found `Option<_>`
  |
  = note: expected struct `Arc<Option<{integer}>>`
               found enum `Option<_>`
```

This makes it more obvious that a Deref is available, and gives a suggestion on how to use it in order to fix the issue at hand.

…kingjubilee,jieyouxu,tgross35

Updates Solaris target information, adds Solaris maintainer

Fix ICE when multiple supertrait substitutions need assoc but only one is provided

Dyn traits must have all of their associated types constrained either by:
1. writing them in the dyn trait itself as an associated type bound, like `dyn Iterator<Item = u32>`,
2. A supertrait bound, like `trait ConstrainedIterator: Iterator<Item = u32> {}`, then you may write `dyn ConstrainedIterator` which doesn't need to mention `Item`.

However, the object type lowering code did not consider the fact that there may be multiple supertraits with different substitutions, so it just used the associated type's *def id* as a key for keeping track of which associated types are missing:

https://github.com/rust-lang/rust/blob/1fc691e6ddc24506b5234d586a5c084eb767f1ad/compiler/rustc_hir_analysis/src/hir_ty_lowering/dyn_compatibility.rs#L131

This means that we can have missing associated types when there are mutliple supertraits with different substitutions and only one of them is constrained, like:

```rust
trait Sup<T> {
    type Assoc: Default;
}

impl<T: Default> Sup<T> for () {
    type Assoc = T;
}
impl<T: Default, U: Default> Dyn<T, U> for () {}

trait Dyn<A, B>: Sup<A, Assoc = A> + Sup<B> {}
```

The above example allows you to name `<dyn Dyn<i32, u32> as Sup<u32>>::Assoc` even though it is not possible to project since it's neither constrained by a manually written projection bound or a supertrait bound. This successfully type-checks, but leads to a codegen ICE since we are not able to project the associated type.

This PR fixes the validation for checking that a dyn trait mentions all of its associated type bounds. This is theoretically a breaking change, since you could technically use that `dyn Dyn<A, B>` type mentionedin the example above without actually *projecting* to the bad associated type, but I don't expect it to ever be relevant to a user since it's almost certainly a bug. This is corroborated with the crater results[^crater], which show no failures[^unknown].

Crater: rust-lang#133392 (comment)

Fixes rust-lang#133388

[^crater]: I cratered this originally with rust-lang#133397, which is a PR that is stacked on top, then re-ran crater with just the failures from that PR.
[^unknown]: If you look at the crater results, it shows all of the passes as "unknown". I believe this is a crater bug, since looking at the results manually shows them as passes.

…documentation, r=tgross35

Add documentation for anonymous pipe module

Tracking issue: rust-lang#127154

`@NobodyXu` I've been using this feature lately and thought I might contribute with some documentation. I borrowed liberally from [os_pipe](https://docs.rs/os_pipe/latest/os_pipe/) so thanks to `@oconnor663.`

…_version, r=tgross35

Doc: Extend for tuples to be stabilized in 1.85.0

I assumed the RUSTC_CURRENT_VERSION would be replaced automatically, but it doesn't look like it on the nightly docs page. Sorry!

…olnay

Clean up `infer_return_ty_for_fn_sig`

The code for lowering fn signatures from HIR currently is structured to prefer the recovery path (where users write `-> _`) over the good path. This PR pulls the recovery code out into a separate fn.

Review w/o whitespace

…iler-errors

Arbitrary self types v2: Weak & NonNull diagnostics

This builds on top of rust-lang#134262 which is more urgent to review and merge first. I'll likely rebase this PR once that lands.

This is the first part of the diagnostic enhancements planned for Arbitrary Self Types v2.

Various types can be used as method receivers, such as `Rc<>`, `Box<>` and `Arc<>`. The arbitrary self types v2 work allows further types to be made method receivers by implementing the Receiver trait.

With that in mind, it may come as a surprise to people when certain common types do not implement Receiver and thus cannot be used as a method receiver.

The RFC for arbitrary self types v2 therefore proposes emitting specific
lint hints for these cases:
* `NonNull`
* `Weak`
* Raw pointers

The code already emits a hint for this third case, in that it advises folks that the `arbitrary_self_types_pointers` feature may meet their need. This PR adds diagnostic hints for the `Weak` and `NonNull` cases.

Tracking issue rust-lang#44874

r? `@wesleywiser`